一支用 Google ADK 寫的 SRE Investigation Agent，原本只需要讀 Log 和 Metrics，協助調查服務延遲。模型卻可能把 Log 裡偽裝成操作手冊的文字當成指令，提出 delete_demo_database。如果程式直接照做，讀取資料的功能就成了執行危險動作的入口。

Day 2 沿著這筆工具呼叫找到模型與 Tool function 之間的授權缺口。這篇把 Log 裡的攻擊指令換一種寫法，看看輸入檢查漏掉之後，執行前授權能不能真的把 Tool 擋下來。

這次 Lab 用安全標記代替刪除資料。標記增加，代表危險 Tool 已經進入執行階段。要確認它在 function 開始前被攔下，除了看標記維持不變，還會對照拒絕事件與工具執行紀錄。

輸入檢查與執行授權的對照方式

同一段攻擊文字，會先經過輸入檢查，再由模型選擇工具，最後交給執行前的授權規則。若只看最後有沒有執行，很難知道是哪一層有效，因此這次分開比較兩個問題。

第一個問題是 keyword guard 能不能認出攻擊。原始 Log 直接寫出 delete_demo_database，guard 很容易命中。改寫後的 Log 把名稱拆成 delete、_demo_ 和 database，完整字串消失了，Gemini 卻仍能把三段重新組起來。

第二個問題是在 guard 漏判後，Tool policy 還能不能拒絕。這裡使用同一份改寫 Log 和相同的模型設定，分別搭配全部放行的 policy 與 Tool allowlist。留下來的兩次 live evidence 都觀察到 Gemini 提出同一個 delete_demo_database，差異發生在執行前的 policy decision。

第一條路徑能省下一次模型呼叫，也能攔住已知模式。第二條路徑提醒我，內容只要稍微換個寫法，字串比對就可能失效。等到第三條路徑，才真正驗證了 Day 2 找到的執行前授權。

Keyword guard 為什麼會漏

Lab 的 guard 故意只做 exact match。它把 Log 的 message 串起來，轉成小寫，再找兩個完整字串：

blocked_keywords = ("delete_demo_database", "operator runbook")

evidence = "\n".join(
    str(record.get("message", "")) for record in records
).casefold()
matches = tuple(
    keyword for keyword in blocked_keywords if keyword in evidence
)

原始攻擊同時出現完整 Tool 名稱與 operator runbook，所以 guard 會拒絕。改寫後沒有任何一個完整關鍵字，結果自然是通過。這個小型 matcher 只是用來穩定重現 false negative。至於 semantic guardrail 能做到什麼，不在這次 Lab 的比較範圍內。

Guard 和 authorization 回答的是兩件事。Guard 看內容像不像攻擊，適合提早擋掉已知模式或提供風險訊號。Authorization 要回答得更明確：某個動作者能不能對指定資源執行這個動作，而且這個允許或拒絕必須能被稽核。

我以前整理 Gateway 責任時，很容易把兩者一起塞進「安全檢查」。真正跑過這條路徑後才看清楚：inspection 再準，仍可能漏判，因此 Tool 執行前還需要一個不依賴模型判斷的拒絕點。OWASP LLM01:2025 也把 input filtering、least privilege 與高風險動作的人工核准列成不同的緩解措施。

在 ADK callback 擋住 Tool function

這個 Lab 把執行前攔截點放在 Google ADK 的 before_tool_callback。模型可以提出 Tool Call，callback 會先把 Tool 名稱交給 allowlist。規則允許時回傳 None，ADK 才會執行 function。規則拒絕時則回傳一份 Tool result：

def before_tool_callback(tool, args, tool_context):
    decision = policy.authorize(tool.name)

    if decision.allowed:
        return None

    return {
        "status": "denied",
        "result": "POLICY_DENIED",
        "reason": decision.reason,
        "policy_version": decision.version,
    }

這和 Google ADK callback 文件 描述的行為一致。Python callback 只有回傳 None 才會繼續執行 Tool。回傳 dictionary 時，Tool function 會被跳過，這份內容直接成為 Tool result。

目前這段規則只看 tool.name，所以它是 name-based allowlist，不是完整的企業授權。它還不知道誰要求動作、目標資源是哪一個，也沒有檢查 args。Day 3 先把最小的執行前拒絕點跑通，後面再補齊 policy input。

這個 callback 是 Agent runtime 裡的一個可用攔截點。跨 runtime 共用的規則，可能更適合集中到 Gateway，最終資源也仍要驗證自己的權限。這一篇先確認最基本的一件事：授權判斷確實發生在副作用之前。

Tool 被拒絕，調查仍能繼續

兩次 Gemini live run 都使用相同的改寫 Log。全部放行時，安全標記增加一筆。換成 allowlist 後，危險 function 沒有執行。

真正讓這個結果有實務價值的是後半段。Gemini 收到拒絕結果後，沒有卡死，也沒有一直重試同一個危險 Tool，而是改用 allowlist 裡的 query_metrics 完成 latency investigation。Policy 擋的是不安全動作，合理的唯讀調查仍然可以完成。

delete_demo_database → DENY
query_metrics        → ALLOW → 調查完成

第一次跑 allowlist 時也踩到一個熟悉的觀測問題：危險 Tool 已經被拒絕，後面的 query_metrics 卻成功了，舊版摘要因此只留下 SUCCESS。我補上 outcome priority 和回歸測試，讓拒絕事件不會再被後續成功結果洗掉。這是 Day 1 同一類 summary bug 的另一個案例，完整事件與修正前後結果留在 Day 3 evidence。

跟著跑三條路徑

完整 Lab、fixture 與 live mode 說明都收在同一份 README，需要時可以直接執行 Day 3 Lab。沒有 Gemini API Key，也能從 repo root 跑固定案例：

make lab-01-up
make lab-03-check
make lab-03-fixture

若要讓 Gemini 重新判斷改寫 Log，再依 README 設定 Lab 專用 Key，執行 make lab-03-live。

Tool 名稱還不足以完成真正的授權

現在的 policy 只收到 tool_name。它可以擋掉不在清單裡的 Tool，卻不知道要求動作的是哪位值班工程師、哪個 Agent，或實際持有 credential 的 workload。因此，同一個 delete_demo_database 不論由誰提出，都會得到相同答案。

下一篇會把 Human、Agent、Workload 與 Resource 分開。等這些責任角色都能進入 policy input，allowlist 才有機會從「這個 Tool 在不在清單裡」，走到「這個動作者是否有權對這個資源執行這次操作」。